Subject: Requirements

From: "Marcia Peters (8-444-4380)" <[email-masked]>
Date: Wed, 2 Nov 94 16:23:49 EST

Comments on requirements proposal, and some additional requirements:

>Jim Cobban writes
>
>1) From the point of view of network management there should be a
>   one-to-one correspondence between the Port component as viewed by
>   APPN and a Port as represented by an electrical interface.

I agree

>2) Where public networks support switched connections with a universal
>   addressing scheme and transitive connectivity they should also
>   support connection networks.  This implies the need to specify the
>   exact format of the DLC specific subfield[s] of the TG Descriptor
>   control vector (X'46') for interoperability.  In this the working
>   group will continue an activity started by the DLUR SIG.

I don't know what "transitive connectivity" means (A can call B,
and B can call A?).  Other than that, I agree.

>3) Where public networks support multicasting, support for discovery
>   should be described.

What do other SIG members think about including topic in this
siglet's scope of work?  It would improve APPN's usability and put it
on a par with RFC 1577 ("Classical IP over ATM").  On the other
hand it isn't required for basic CN functionality or interoperability.
I guess I hope the SIGlet agrees to work on this requirement.

>4) Since there are a very wide, and growing, set of different public
>   data network interfaces, the support for the unique characteristics
>   of these interfaces should be completely isolated in the DLC
>   specific code.  This is different from the current implementations
>   where knowledge of the 6+1 byte addresses of SATF networks is
>   distributed through CS, SS, and TRS.  We do not want to further
>   complicate these components with knowledge of the internals of
>   additional DLC types.  The existing SATF specific addressing support
>   should be phased out of implementations.

I agree

Additionally
____________

(5) In order for route selection and circuit establishment over
    switched subnets to be consistent across different APPN products, a
    consistent mapping of subnet services to APPN TG characteristics
    needs to be defined.  This work involves several subtasks:

    a.  Characterize the services that the subnet can provide.  I.e. CIR,
        best-effort, congestion notification, user information elements
        on call setup, multicast...whatever

    b.  Define how to represent these services in terms of TG
        characteristics.  For example, a physical link from a Frame
        Relay TE to a FH can support SVCs with varied CIRs.  One could
        represent all possible CIRs in APPN as many TGs.  But to avoid a
        "TG explosion," some other method is needed to represent the
        potential connectivity.

    c.  Figure out which part of the signalling information needs to be
        sent around the network in TG descriptors, and which part is
        only needed locally at the node attached to the subnet.

    d.  Specify an inverse mapping from TG characteristics to subnet-
        specific signalling information, for use at call-setup time.

Also, this SIGlet needs to figure out its relationship to the APPN/ATM
BOF so that work is coordinated and no overlap occurs.

Marcia Peters................................APPN Architecture Team, IBM